Presently, large volumes of data are delivered over the Internet by server computers to client computing devices such as desktop computers, laptops and various handheld digital devices using a communication protocol called ‘Hyper Text Transfer Protocol’ (HTTP). The HTTP protocol strictly defines the interaction between a client device that sends requests for data, and a server that supplies the data. A client, after sending the request for data to the server, waits for the server's response, and then normally, upon receipt of data, delivers the data to the end user. The server is usually implemented by a software component called a ‘web-server’. In many cases, the client is implemented by a software component called a ‘web-browser’, which provides a user interface for the client to enable an end user to access and observe content (e.g. documents, images, audio files, etc.) available on the World-Wide Web in a rendered form. The web-browser interprets and renders HTML content for presentation to the user, accepts user input (e.g., mouse-clicks or keyboard strokes), and provides hyper-linking functionality. Web-browsers may also implement other functions such as rendering images, bookmarking, maintaining history lists for navigation, and caching. A web-browser may be included with a computer operating system and, as such, can be pre-installed on a computer along with the operating system (see, e.g., Microsoft Windows and Microsoft Internet Explorer). Additionally, as with other computer software, web-browsers may also be obtained for later installation by an end user (see, e.g. Netscape Navigator).
Rapid expansion in Internet usage by businesses, banking and direct consumer shopping led to the definition of a standard approach for sending encrypted HTTP data between HTTP clients and servers. This approach (also known as HTTPS) was first implemented by Netscape as HTTP over a Secure-Socket Layer (SSL) TCP/IP connection. The HTTPS protocol allowed end-users and corporations to safely send credit-card and other sensitive information over the internet. More specifically, it prevents eavesdropping, message forgery and tampering of HTTP data sent between client/server applications. The first implementations of HTTPS utilized 40-bit encryption while the latest standard (HTTP over TLS described in an article by E. Rescorla entitled “Request for Comments: 2818, HTTP over TLS,” Network Working Group, May 2000), facilitates the use of powerful 128-bit encryption.
The underlying implementations of SSL and TLS are described in the article by A. Freier et al. and in the article by T. Dierks et al. respectively. Although the mechanisms are different, both SSL and TLS essentially involve several common stages:                1) Protocol version identification between web-browser and web-server.        2) Transmission of webserver's public key to the web-browser (the signed public key is also known as a Certificate).        3) Web-browser verifies the Certificate by communicating with a trusted entity (known as a Root Certificate Authority). This ensures that the web-browser is communicating with the intended web-server.        4) Negotiation and exchange of ‘symmetric encryption-key’ between web-browser and web-server.        5) The symmetric encryption-key is then used to establish an SSL or TLS ‘channel’ between the web-browser and web-server.        6) Encryption of all HTTP payload data between web-browser and web-server over the SSL/TLS channel.        
It is imperative for SSL and TLS functionality to be implemented by the web-browser so that the SSL/TLS ‘channel’ is established directly from the web-browser. This guarantees the encryption and security of all HTTP data originating from the web-browser and received from the web-server. Reference is made to FIG. 1 which depicts the aforementioned scenario.
Now consider the compression of HTTPS data (HTTP payload data sent over an SSL or TLS channel) in order to reduce the volume of data transmission. Content-encoding methods inherently present in the HTTP standard (section 3.5 of the article by R. Fielding et al.) can be used to reduce the volume of data sent in HTTPS transactions. These methods consist of a class of lossless compression algorithms such as gzip, compress and deflate which can be supported within web-browsers and web-servers.
Unfortunately, custom approaches (e.g., proprietary data-compression) or any other proprietary or custom data processing cannot be supported by HTTPS. HTTPS does not provide for a standard interface or mechanism to facilitate custom data transformation. More specifically, the encryption of HTTP data actually randomizes the original source HTTP data. In an information-theoretic sense, the entropy of the encrypted data is significantly higher than the original source data. Significant randomization of source data limits the effectiveness of data-compression. The encrypted data also makes it difficult to do many other types of desirable data processing operations such as data recording, data monitoring, or data alteration. Since SSL and TLS are designed to prevent data-tampering or “man in the middle” viewing, retrieving the original source HTTP data is extremely difficult.